പൈത്തൺ മൈക്രോസർവീസുകളിൽ ഒരു സർവീസ് മെഷ് നടപ്പാക്കുന്നതിനുള്ള ആഗോള ഡെവലപ്പർമാർക്കുള്ള സമഗ്ര ഗൈഡ്. Istio, Linkerd, സുരക്ഷ, നിരീക്ഷണം, ട്രാഫിക് മാനേജ്മെന്റ് എന്നിവയെക്കുറിച്ച് അറിയുക.
പൈത്തൺ മൈക്രോസർവീസുകൾ: സർവീസ് മെഷ് നടപ്പാക്കൽ ഒരു ആഴത്തിലുള്ള പഠനം
സോഫ്റ്റ്വെയർ ഡെവലപ്മെന്റ് ലാൻഡ്സ്കേപ്പ് മൈക്രോസർവീസസ് ആർക്കിടെക്ചറിലേക്ക് അടിമുടി മാറിയിരിക്കുന്നു. മോണോലിത്തിക് ആപ്ലിക്കേഷനുകളെ ചെറുതും സ്വതന്ത്രമായി വിന്യസിക്കാവുന്നതുമായ സേവനങ്ങളായി വിഭജിക്കുന്നത് സമാനതകളില്ലാത്ത ഊർജ്ജസ്വലത, അളവെടുക്കൽ, പ്രതിരോധശേഷി എന്നിവ നൽകുന്നു. പൈത്തൺ, അതിൻ്റെ വ്യക്തമായ സിൻ്റാക്സും ഫാസ്റ്റ്എപിഐ, ഫ്ലാസ്ക് പോലുള്ള ശക്തമായ ചട്ടക്കൂടുകളും കാരണം, ഈ സേവനങ്ങൾ നിർമ്മിക്കുന്നതിനുള്ള ഒരു പ്രധാന തിരഞ്ഞെടുപ്പായി മാറിയിരിക്കുന്നു. എന്നിരുന്നാലും, ഈ വിതരണ ലോകം വെല്ലുവിളികളില്ലാത്തതല്ല. സേവനങ്ങളുടെ എണ്ണം വർദ്ധിക്കുന്നതിനനുസരിച്ച്, അവയുടെ ആശയവിനിമയങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിലെ സങ്കീർണ്ണതയും വർദ്ധിക്കുന്നു. ഇവിടെയാണ് ഒരു സർവീസ് മെഷ് പ്രയോജനപ്പെടുന്നത്.
ഈ സമഗ്ര ഗൈഡ് പൈത്തൺ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്ന സോഫ്റ്റ്വെയർ എഞ്ചിനീയർമാർ, ഡെവോപ്സ് പ്രൊഫഷണലുകൾ, വാസ്തുശില്പികൾ എന്നിവരെ ലക്ഷ്യമിട്ടുള്ളതാണ്. ഒരു സർവീസ് മെഷ് 'നല്ലൊരു' ഘടകം മാത്രമല്ല, വലിയ തോതിലുള്ള മൈക്രോസർവീസുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് അത്യാവശ്യമായ ഒരു ഘടകമാണ് എന്ന് ഞങ്ങൾ പരിശോധിക്കും. ഒരു സർവീസ് മെഷ് എന്താണെന്നും, അത് എങ്ങനെ നിർണ്ണായക പ്രവർത്തനപരമായ വെല്ലുവിളികളെ പരിഹരിക്കുന്നുവെന്നും, പൈത്തൺ അടിസ്ഥാനമാക്കിയുള്ള മൈക്രോസർവീസസ് പരിതസ്ഥിതിയിൽ അത് എങ്ങനെ നടപ്പിലാക്കാമെന്നും ഞങ്ങൾ വിശദീകരിക്കും.
പൈത്തൺ മൈക്രോസർവീസുകൾ എന്തൊക്കെയാണ്? ഒരു വേഗത്തിലുള്ള പുനരവലോകനം
മെഷിലേക്ക് കടക്കുന്നതിന് മുമ്പ്, നമുക്ക് ഒരു പൊതു അടിത്തറ സ്ഥാപിക്കാം. ഒരു മൈക്രോസർവീസ് ആർക്കിടെക്ചർ എന്നത് ഒരു വലിയ ആപ്ലിക്കേഷൻ പലതരം ലൂസ്ലി കപ്ൾഡ് ആയതും സ്വതന്ത്രമായി വിന്യസിക്കാവുന്നതുമായ ചെറിയ സേവനങ്ങളായി 구성하는 ഒരു സമീപനമാണ്. ഓരോ സേവനവും സ്വയം അടങ്ങിയതും, ഒരു പ്രത്യേക ബിസിനസ്സ് കഴിവിന് ഉത്തരവാദപ്പെട്ടതും, മറ്റ് സേവനങ്ങളുമായി ഒരു നെറ്റ്വർക്ക് വഴി, സാധാരണയായി API-കൾ (REST അല്ലെങ്കിൽ gRPC പോലുള്ളവ) വഴി ആശയവിനിമയം നടത്തുന്നതുമാണ്.
പൈത്തൺ ഈ പാരാഡിഗ്മയ്ക്ക് അസാധാരണമായി അനുയോജ്യമാണ് കാരണം:
- ലാളിത്യവും വികസന വേഗതയും: പൈത്തണിൻ്റെ വായിക്കാൻ എളുപ്പമുള്ള സിൻ്റാക്സ് ടീമുകൾക്ക് സേവനങ്ങൾ വേഗത്തിൽ നിർമ്മിക്കാനും പരിഷ്കരിക്കാനും അനുവദിക്കുന്നു.
- സമ്പന്നമായ പരിസ്ഥിതി: വെബ് സെർവറുകൾ (FastAPI, Flask) മുതൽ ഡാറ്റാ സയൻസ് (Pandas, Scikit-learn) വരെയുള്ള എല്ലാത്തിനും ലൈബ്രറികളുടെയും ചട്ടക്കൂടുകളുടെയും ഒരു വലിയ ശേഖരം.
- പ്രകടനം: സ്റ്റാർലെറ്റ്, പൈഡാൻ്റിക് എന്നിവയിൽ നിർമ്മിച്ച ഫാസ്റ്റ്എപിഐ പോലുള്ള ആധുനിക അസിൻക്രണസ് ചട്ടക്കൂടുകൾ, I/O-ബൗണ്ട് ടാസ്ക്കുകൾക്ക് NodeJS, Go എന്നിവയുമായി താരതമ്യപ്പെടുത്താവുന്ന പ്രകടനം നൽകുന്നു, ഇത് മൈക്രോസർവീസുകളിൽ സാധാരണമാണ്.
ഒരു ആഗോള ഇ-കൊമേഴ്സ് പ്ലാറ്റ്ഫോം സങ്കൽപ്പിക്കുക. ഒരൊറ്റ വലിയ ആപ്ലിക്കേഷന് പകരം, ഇത് പോലുള്ള മൈക്രോസർവീസുകൾ ഉൾക്കൊള്ളാം:
- ഉപഭോക്തൃ സേവനം: ഉപഭോക്തൃ അക്കൗണ്ടുകളും പ്രാമാണീകരണവും കൈകാര്യം ചെയ്യുന്നു.
- ഉൽപ്പന്ന സേവനം: ഉൽപ്പന്ന കാറ്റലോഗും ഇൻവെൻ്ററിയും കൈകാര്യം ചെയ്യുന്നു.
- ഓർഡർ സേവനം: പുതിയ ഓർഡറുകളും പേയ്മെൻ്റും പ്രോസസ്സ് ചെയ്യുന്നു.
- ഷിപ്പിംഗ് സേവനം: ഷിപ്പിംഗ് ചെലവുകൾ കണക്കാക്കുകയും ഡെലിവറി ക്രമീകരിക്കുകയും ചെയ്യുന്നു.
പൈത്തണിൽ എഴുതിയ ഓർഡർ സേവനത്തിന്, ഉപഭോക്താവിനെ സാധൂകരിക്കാൻ ഉപഭോക്തൃ സേവനവുമായും സ്റ്റോക്ക് പരിശോധിക്കാൻ ഉൽപ്പന്ന സേവനവുമായും സംസാരിക്കേണ്ടതുണ്ട്. ഈ ആശയവിനിമയം നെറ്റ്വർക്ക് വഴി സംഭവിക്കുന്നു. ഇപ്പോൾ, ഡസൻ കണക്കിന് അല്ലെങ്കിൽ നൂറുകണക്കിന് സേവനങ്ങളിലേക്ക് ഇത് ഗുണിക്കുക, സങ്കീർണ്ണത പുറത്തുവരാൻ തുടങ്ങും.
ഒരു വിതരണ ഘടനയുടെ സ്വാഭാവിക വെല്ലുവിളികൾ
നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ഘടകങ്ങൾ ഒരു നെറ്റ്വർക്കിലൂടെ ആശയവിനിമയം നടത്തുമ്പോൾ, നെറ്റ്വർക്കിന്റെ സ്വാഭാവികമായ വിശ്വാസ്യതയില്ലായ്മയെല്ലാം നിങ്ങൾക്ക് ലഭിക്കുന്നു. ഒരു മോണോലിത്തിൻ്റെ ലളിതമായ ഫംഗ്ഷൻ കോൾ, സാധ്യതയുള്ള പ്രശ്നങ്ങളാൽ നിറയുന്ന ഒരു സങ്കീർണ്ണമായ നെറ്റ്വർക്ക് അഭ്യർത്ഥനയായി മാറുന്നു. ഇവ പലപ്പോഴും "Day 2" പ്രവർത്തന പ്രശ്നങ്ങൾ എന്ന് വിളിക്കപ്പെടുന്നു, കാരണം അവ ആദ്യത്തെ വിന്യാസത്തിന് ശേഷം പ്രകടമാകും.
നെറ്റ്വർക്ക് വിശ്വാസ്യതയില്ലായ്മ
ഓർഡർ സേവനം അതിനെ വിളിക്കുമ്പോൾ ഉൽപ്പന്ന സേവനം പ്രതികരിക്കാൻ വളരെ സമയമെടുത്താലോ അല്ലെങ്കിൽ താൽക്കാലികമായി ലഭ്യമല്ലെങ്കിലോ എന്തു സംഭവിക്കും? അഭ്യർത്ഥന പരാജയപ്പെട്ടേക്കാം. ആപ്ലിക്കേഷൻ കോഡ് ഇത് കൈകാര്യം ചെയ്യേണ്ടതുണ്ട്. ഇത് വീണ്ടും ശ്രമിക്കണോ? എത്ര തവണ? എന്ത് കാലതാമസത്തോടെ (exponential backoff)? ഉൽപ്പന്ന സേവനം പൂർണ്ണമായി ഓഫാണെങ്കിലോ? അത് വീണ്ടെടുക്കാൻ അനുവദിക്കുന്നതിന് കുറച്ച് സമയം അഭ്യർത്ഥനകൾ അയക്കുന്നത് നിർത്തണോ? ഈ ലോജിക്, വീണ്ടും ശ്രമിക്കൽ, ടൈംഔട്ടുകൾ, സർക്യൂട്ട് ബ്രേക്കറുകൾ എന്നിവ ഉൾപ്പെടെ, ഓരോ നെറ്റ്വർക്ക് കോളുകൾക്കും ഓരോ സേവനത്തിലും നടപ്പിലാക്കേണ്ടതുണ്ട്. ഇത് ആവർത്തന സ്വഭാവമുള്ളതും, പിഴവുകൾ സംഭവിക്കാൻ സാധ്യതയുള്ളതും, നിങ്ങളുടെ പൈത്തൺ ബിസിനസ്സ് ലോജിക് വൃത്തികേടാക്കുന്നതുമാണ്.
നിരീക്ഷിക്കാനുള്ള ശൂന്യത
ഒരു മോണോലിത്തിൽ, പ്രകടനം മനസ്സിലാക്കുന്നത് താരതമ്യേന ലളിതമാണ്. മൈക്രോസർവീസസ് പരിതസ്ഥിതിയിൽ, ഒരു ഉപഭോക്തൃ അഭ്യർത്ഥന അഞ്ച്, പത്ത്, അല്ലെങ്കിൽ അതിൽ കൂടുതൽ സേവനങ്ങളിലൂടെ കടന്നുപോയേക്കാം. ആ അഭ്യർത്ഥന വളരെ സമയമെടുത്താൽ, തടസ്സം എവിടെയാണ്? ഇത് ഉത്തരം നൽകുന്നതിന് ഇവയ്ക്ക് ഒരു ഏകീകൃത സമീപനം ആവശ്യമാണ്:
- മെട്രിക്സ്: ഓരോ സേവനത്തിൽ നിന്നും അഭ്യർത്ഥനയുടെ കാലതാമസം, പിഴവ് നിരക്കുകൾ, ട്രാഫിക് അളവ് ( "ഗോൾഡൻ സിഗ്നലുകൾ") എന്നിവ പോലുള്ള മെട്രിക്കുകൾ സ്ഥിരമായി ശേഖരിക്കുന്നു.
- ലോഗിംഗ്: നൂറുകണക്കിന് സേവന ഇൻസ്റ്റൻസുകളിൽ നിന്നുള്ള ലോഗുകൾ ശേഖരിക്കുകയും ഒരു പ്രത്യേക അഭ്യർത്ഥനയുമായി ബന്ധപ്പെടുത്തുകയും ചെയ്യുന്നു.
- വിതരണ നിരീക്ഷണം: മുഴുവൻ കോൾ ഗ്രാഫും ദൃശ്യവൽക്കരിക്കാനും കാലതാമസം കണ്ടെത്താനും അത് സ്പർശിക്കുന്ന എല്ലാ സേവനങ്ങളിലൂടെയും ഒരു അഭ്യർത്ഥനയുടെ യാത്ര പിന്തുടരുന്നു.
ഇത് സ്വമേധയാ നടപ്പിലാക്കുന്നത് ഓരോ പൈത്തൺ സേവനത്തിലും വിപുലമായ ഉപകരണങ്ങളും നിരീക്ഷണ ലൈബ്രറികളും ചേർക്കുന്നതിന് അർത്ഥമാക്കുന്നു, ഇത് സ്ഥിരതയിൽ വ്യത്യാസപ്പെടുകയും പരിപാലന ഭാരം വർദ്ധിപ്പിക്കുകയും ചെയ്യും.
സുരക്ഷയുടെ ജാലവിദ്യ
നിങ്ങളുടെ ഓർഡർ സേവനത്തിനും ഉപഭോക്തൃ സേവനത്തിനും ഇടയിലുള്ള ആശയവിനിമയം സുരക്ഷിതവും എൻക്രിപ്റ്റ് ചെയ്തതും ആണെന്ന് എങ്ങനെ ഉറപ്പാക്കാം? ഉൽപ്പന്ന സേവനത്തിലെ സുപ്രധാന ഇൻവെൻ്ററി എൻഡ്പോയിന്റുകളിലേക്ക് ഓർഡർ സേവനത്തിന് മാത്രമേ പ്രവേശനം അനുവദിക്കൂ എന്ന് എങ്ങനെ ഉറപ്പ് വരുത്താം? ഒരു പരമ്പരാഗത സജ്ജീകരണത്തിൽ, നിങ്ങൾക്ക് നെറ്റ്വർക്ക് തലത്തിലുള്ള നിയമങ്ങളെ (ഫയർവാൾ) ആശ്രയിക്കാൻ കഴിഞ്ഞേക്കും അല്ലെങ്കിൽ ഓരോ ആപ്ലിക്കേഷനിലും രഹസ്യങ്ങളും പ്രാമാണീകരണ ലോജിക് ഉൾക്കൊള്ളാൻ കഴിഞ്ഞേക്കും. ഇത് വലിയ തോതിൽ കൈകാര്യം ചെയ്യാൻ വളരെ ബുദ്ധിമുട്ടുള്ളതാകുന്നു. നിങ്ങൾക്ക് ഒരു സീറോ-ട്രസ്റ്റ് നെറ്റ്വർക്ക് ആവശ്യമാണ്, അവിടെ ഓരോ സേവനവും ഓരോ കോളും പ്രാമാണീകരിക്കുകയും അംഗീകരിക്കുകയും ചെയ്യുന്നു, ഇത് Mutual TLS (mTLS) എന്നും ഫൈൻ-ഗ്രെയിൻഡ് ആക്സസ് കൺട്രോൾ എന്നും അറിയപ്പെടുന്നു.
സങ്കീർണ്ണമായ വിന്യാസങ്ങളും ട്രാഫിക് മാനേജ്മെൻ്റും
ഡൗൺടൈം ഉണ്ടാക്കാതെ നിങ്ങളുടെ പൈത്തൺ അടിസ്ഥാനമാക്കിയുള്ള ഉൽപ്പന്ന സേവനത്തിൻ്റെ പുതിയ പതിപ്പ് എങ്ങനെ റിലീസ് ചെയ്യാം? ഒരു സാധാരണ തന്ത്രം കാനറി റിലീസ് ആണ്, അവിടെ നിങ്ങൾ ലൈവ് ട്രാഫിക്കിൻ്റെ ഒരു ചെറിയ ശതമാനം (ഉദാഹരണത്തിന്, 1%) പുതിയ പതിപ്പിലേക്ക് പതുക്കെ റൂട്ട് ചെയ്യുന്നു. അത് നന്നായി പ്രവർത്തിക്കുകയാണെങ്കിൽ, നിങ്ങൾ ട്രാഫിക് ക്രമേണ വർദ്ധിപ്പിക്കും. ഇത് നടപ്പിലാക്കുന്നതിന് പലപ്പോഴും ലോഡ് ബാലൻസർ അല്ലെങ്കിൽ API ഗേറ്റ്വേ തലത്തിൽ സങ്കീർണ്ണമായ ലോജിക് ആവശ്യമാണ്. പരിശോധന ആവശ്യത്തിനായി A/B ടെസ്റ്റിംഗ് അല്ലെങ്കിൽ ട്രാഫിക് മിററിംഗ് എന്നിവയ്ക്കും ഇത് ബാധകമാണ്.
സർവീസ് മെഷ് പ്രവേശിക്കുന്നു: സേവനങ്ങൾക്കുള്ള നെറ്റ്വർക്ക്
ഒരു സർവീസ് മെഷ് എന്നത് ഈ വെല്ലുവിളികളെ നേരിടുന്ന ഒരു സമർപ്പിത, കോൺഫിഗർ ചെയ്യാൻ കഴിയുന്ന അടിസ്ഥാന സൗകര്യ ലേയറാണ്. ഇത് നിങ്ങളുടെ നിലവിലുള്ള നെറ്റ്വർക്കിന് മുകളിൽ (കുബർനെറ്റെസ് നൽകുന്നതുപോലുള്ള) എല്ലാ സേവന-ടു-സേവന ആശയവിനിമയത്തെയും കൈകാര്യം ചെയ്യുന്ന ഒരു നെറ്റ്വർക്കിംഗ് മോഡലാണ്. ഇതിൻ്റെ പ്രാഥമിക ലക്ഷ്യം ഈ ആശയവിനിമയം വിശ്വസനീയവും സുരക്ഷിതവും നിരീക്ഷിക്കാവുന്നതുമാക്കുക എന്നതാണ്.
പ്രധാന ഘടകങ്ങൾ: കൺട്രോൾ പ്ലെയിനും ഡാറ്റാ പ്ലെയിനും
ഒരു സർവീസ് മെഷിന് രണ്ട് പ്രധാന ഭാഗങ്ങളുണ്ട്:
- ഡാറ്റാ പ്ലെയിൻ: ഇത് ലൈറ്റ്വെയ്റ്റ് നെറ്റ്വർക്ക് പ്രോക്സികളുടെ ഒരു കൂട്ടമാണ്, ഇത് സൈഡ്കാർസ് എന്ന് വിളിക്കപ്പെടുന്നു, ഇത് നിങ്ങളുടെ മൈക്രോസർവീസിൻ്റെ ഓരോ ഇൻസ്റ്റൻസിനൊപ്പം വിന്യസിക്കപ്പെടുന്നു. ഈ പ്രോക്സികൾ നിങ്ങളുടെ സേവനത്തിലേക്കും അതിൽ നിന്നുമുള്ള എല്ലാ ഇൻകമിംഗ്, ഔട്ട്ഗോയിംഗ് നെറ്റ്വർക്ക് ട്രാഫിക്കിനെയും തടയുന്നു. നിങ്ങളുടെ സേവനം പൈത്തണിലാണ് എഴുതിയിരിക്കുന്നതെന്ന് അവർക്കറിയില്ല അല്ലെങ്കിൽ ശ്രദ്ധിക്കുന്നില്ല; അവർ നെറ്റ്വർക്ക് തലത്തിൽ പ്രവർത്തിക്കുന്നു. സർവീസ് മെഷുകളിൽ ഉപയോഗിക്കുന്ന ഏറ്റവും പ്രചാരമുള്ള പ്രോക്സി Envoy ആണ്.
- കൺട്രോൾ പ്ലെയിൻ: ഇത് സർവീസ് മെഷിൻ്റെ "മസ്തിഷ്കമാണ്". ഇത് ഓപ്പറേറ്ററായ നിങ്ങൾ ഇടപഴകുന്ന ഘടകങ്ങളുടെ ഒരു കൂട്ടമാണ്. "ഉൽപ്പന്ന സേവനത്തിലേക്കുള്ള പരാജയപ്പെട്ട അഭ്യർത്ഥനകൾ 3 തവണ വരെ വീണ്ടും ശ്രമിക്കുക" പോലുള്ള ഉയർന്ന തലത്തിലുള്ള നിയമങ്ങളും നയങ്ങളും നിങ്ങൾ കൺട്രോൾ പ്ലെയിന് നൽകുന്നു. കൺട്രോൾ പ്ലെയിൻ ഈ നയങ്ങളെ കോൺഫിഗറേഷനുകളായി വിവർത്തനം ചെയ്യുകയും ഡാറ്റാ പ്ലെയിനിലെ എല്ലാ സൈഡ്കാർ പ്രോക്സികളിലേക്കും പുഷ് ചെയ്യുകയും ചെയ്യുന്നു.
പ്രധാന കാര്യം ഇതാണ്: സർവീസ് മെഷ് വ്യക്തിഗത പൈത്തൺ സേവനങ്ങളിൽ നിന്ന് നെറ്റ്വർക്കിംഗ് സംബന്ധമായ കാര്യങ്ങൾക്കുള്ള ലോജിക് പ്ലാറ്റ്ഫോം തലത്തിലേക്ക് മാറ്റുന്നു. നിങ്ങളുടെ ഫാസ്റ്റ്എപിഐ ഡെവലപ്പർക്ക് ഇനി ഒരു വീണ്ടും ശ്രമിക്കൽ ലൈബ്രറി ഇറക്കുമതി ചെയ്യുകയോ mTLS സർട്ടിഫിക്കറ്റുകൾ കൈകാര്യം ചെയ്യുന്ന കോഡ് എഴുതുകയോ ചെയ്യേണ്ടതില്ല. അവർ ബിസിനസ്സ് ലോജിക് എഴുതുന്നു, മെഷ് ബാക്കിയുള്ളവ സുതാര്യമായി കൈകാര്യം ചെയ്യുന്നു.
ഓർഡർ സേവനത്തിൽ നിന്ന് ഉൽപ്പന്ന സേവനത്തിലേക്കുള്ള ഒരു അഭ്യർത്ഥന ഇപ്പോൾ ഇങ്ങനെ ഒഴുകുന്നു: ഓർഡർ സേവനം → ഓർഡർ സേവനം സൈഡ്കാർ → ഉൽപ്പന്ന സേവനം സൈഡ്കാർ → ഉൽപ്പന്ന സേവനം. എല്ലാ മാജിക്കും—വീണ്ടും ശ്രമിക്കൽ, ലോഡ് ബാലൻസിംഗ്, എൻക്രിപ്ഷൻ, മെട്രിക് ശേഖരണം—രണ്ട് സൈഡ്കാറുകൾക്കിടയിൽ സംഭവിക്കുന്നു, കൺട്രോൾ പ്ലെയിൻ കൈകാര്യം ചെയ്യുന്നു.
ഒരു സർവീസ് മെഷിൻ്റെ പ്രധാന തൂണുകൾ
ഒരു സർവീസ് മെഷ് നൽകുന്ന പ്രയോജനങ്ങൾ നാല് പ്രധാന തൂണുകളായി നമുക്ക് വിഭജിക്കാം.
1. വിശ്വാസ്യതയും പ്രതിരോധശേഷിയും
ഒരു സർവീസ് മെഷ് നിങ്ങളുടെ ആപ്ലിക്കേഷൻ കോഡ് മാറ്റാതെ തന്നെ നിങ്ങളുടെ വിതരണ സംവിധാനത്തെ കൂടുതൽ ശക്തമാക്കുന്നു.
- യാന്ത്രിക വീണ്ടും ശ്രമിക്കൽ: ഒരു സേവനത്തിലേക്കുള്ള കോൾ ഒരു താൽക്കാലിക നെറ്റ്വർക്ക് പിഴവോടെ പരാജയപ്പെട്ടാൽ, കോൺഫിഗർ ചെയ്ത നയം അടിസ്ഥാനമാക്കി സൈഡ്കാറിന് യാന്ത്രികമായി അഭ്യർത്ഥന വീണ്ടും ശ്രമിക്കാൻ കഴിയും.
- ടൈംഔട്ടുകൾ: നിങ്ങൾക്ക് സ്ഥിരമായ, സേവന തലത്തിലുള്ള ടൈംഔട്ടുകൾ നടപ്പിലാക്കാൻ കഴിയും. ഒരു താഴെയുള്ള സേവനം 200ms-നുള്ളിൽ പ്രതികരിക്കുന്നില്ലെങ്കിൽ, അഭ്യർത്ഥന വേഗത്തിൽ പരാജയപ്പെടുന്നു, ഇത് വിഭവങ്ങൾ തടയുന്നത് തടയുന്നു.
- സർക്യൂട്ട് ബ്രേക്കറുകൾ: ഒരു സേവന ഇൻസ്റ്റൻസ് സ്ഥിരമായി പരാജയപ്പെട്ടാൽ, സൈഡ്കാറിന് അതിനെ ലോഡ്-ബാലൻസിംഗ് പൂളിൽ നിന്ന് താൽക്കാലികമായി നീക്കം ചെയ്യാൻ കഴിയും (സർക്യൂട്ട് ട്രിപ്പ് ചെയ്യാം). ഇത് കാസ്കേഡിംഗ് പരാജയങ്ങളെ തടയുകയും അനാരോഗ്യകരമായ സേവനത്തിന് വീണ്ടെടുക്കാൻ സമയം നൽകുകയും ചെയ്യുന്നു.
2. ആഴത്തിലുള്ള നിരീക്ഷണം
ട്രാഫിക് നിരീക്ഷിക്കാൻ സൈഡ്കാർ പ്രോക്സി ഒരു മികച്ച സ്ഥാനമാണ്. ഇത് ഓരോ അഭ്യർത്ഥനയും പ്രതികരണവും കാണുന്നതിനാൽ, ഇത് ധാരാളം ടെലിമെട്രി ഡാറ്റ സ്വയം സൃഷ്ടിക്കാൻ കഴിയും.
- മെട്രിക്സ്: കാലതാമസം (p50, p90, p99), വിജയ നിരക്കുകൾ, അഭ്യർത്ഥന അളവ് എന്നിവ ഉൾപ്പെടെ എല്ലാ ട്രാഫിക്കിനും മെഷ് യാന്ത്രികമായി വിശദമായ മെട്രിക്കുകൾ സൃഷ്ടിക്കുന്നു. ഇവ പ്രൊമിഥിയസ് പോലുള്ള ഒരു ഉപകരണം ഉപയോഗിച്ച് സ്കാൻ ചെയ്യാനും ഗ്രാഫാന പോലുള്ള ഡാഷ്ബോർഡിൽ ദൃശ്യവൽക്കരിക്കാനും കഴിയും.
- വിതരണ നിരീക്ഷണം: സൈഡ്കാറുകൾക്ക് ട്രേസ് ഹെഡറുകൾ (B3 അല്ലെങ്കിൽ W3C ട്രേസ് കോൺടെക്സ്റ്റ് പോലെ) സേവന കോളുകളിലുടനീളം ചേർക്കാനും പ്രചരിപ്പിക്കാനും കഴിയും. ഇത് Jaeger അല്ലെങ്കിൽ Zipkin പോലുള്ള നിരീക്ഷണ ഉപകരണങ്ങളെ ഒരു അഭ്യർത്ഥനയുടെ മുഴുവൻ യാത്രയും ഒരുമിപ്പിക്കാൻ അനുവദിക്കുന്നു, ഇത് നിങ്ങളുടെ സിസ്റ്റത്തിൻ്റെ പെരുമാറ്റത്തിൻ്റെ പൂർണ്ണ ചിത്രം നൽകുന്നു.
- ആക്സസ് ലോഗുകൾ: ഓരോ സേവന-ടു-സേവന കോളുകൾക്കും സ്ഥിരമായ, വിശദമായ ലോഗുകൾ നേടുക, ഇത് ഉറവിടം, ലക്ഷ്യം, പാത, കാലതാമസം, പ്രതികരണ കോഡ് എന്നിവ കാണിക്കുന്നു, നിങ്ങളുടെ പൈത്തൺ കോഡിൽ ഒരു "print()" സ്റ്റേറ്റ്മെൻ്റ് പോലും ഇല്ലാതെ.
Kiali പോലുള്ള ഉപകരണങ്ങൾക്ക് ഈ ഡാറ്റ ഉപയോഗിച്ച് നിങ്ങളുടെ മൈക്രോസർവീസുകളുടെ ഒരു തത്സമയ ഡിപൻഡൻസി ഗ്രാഫ് സൃഷ്ടിക്കാൻ പോലും കഴിയും, ഇത് ട്രാഫിക് ഒഴുക്കും ആരോഗ്യ നിലയും തത്സമയം കാണിക്കുന്നു.
3. സാർവത്രിക സുരക്ഷ
ഒരു സർവീസ് മെഷിന് നിങ്ങളുടെ ക്ലസ്റ്ററിനുള്ളിൽ ഒരു സീറോ-ട്രസ്റ്റ് സുരക്ഷാ മോഡൽ നടപ്പിലാക്കാൻ കഴിയും.
- Mutual TLS (mTLS): ഓരോ സേവനത്തിനും മെഷ് യാന്ത്രികമായി ക്രിപ്റ്റോഗ്രാഫിക് ഐഡൻ്റിറ്റികൾ (സർട്ടിഫിക്കറ്റുകൾ) നൽകാൻ കഴിയും. ഇത് സേവനങ്ങൾക്കിടയിലുള്ള എല്ലാ ട്രാഫിക്കിനെയും എൻക്രിപ്റ്റ് ചെയ്യാനും പ്രാമാണീകരിക്കാനും ഇത് ഉപയോഗിക്കുന്നു. ഇത് ഒരു അനധികൃത സേവനത്തിനും മറ്റൊരു സേവനവുമായി സംസാരിക്കാൻ കഴിയില്ലെന്ന് ഉറപ്പാക്കുന്നു, കൂടാതെ ട്രാൻസിറ്റിലുള്ള എല്ലാ ഡാറ്റയും എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുന്നു. ഇത് ലളിതമായ ഒരു കോൺഫിഗറേഷൻ ടോഗിൾ ഉപയോഗിച്ച് പ്രവർത്തനക്ഷമമാക്കുന്നു.
- അംഗീകാര നയങ്ങൾ: നിങ്ങൾക്ക് ശക്തമായ, ഫൈൻ-ഗ്രെയിൻഡ് ആക്സസ് കൺട്രോൾ നിയമങ്ങൾ സൃഷ്ടിക്കാൻ കഴിയും. ഉദാഹരണത്തിന്, "'order-service' ഐഡൻ്റിറ്റിയുള്ള സേവനങ്ങളിൽ നിന്ന് 'product-service' ലെ `/products` എൻഡ്പോയിന്റിലേക്ക് `GET` അഭ്യർത്ഥനകൾ അനുവദിക്കുക, മറ്റെല്ലാതും നിഷേധിക്കുക" എന്ന് പറയുന്ന ഒരു നയം നിങ്ങൾക്ക് എഴുതാം. ഇത് സൈഡ്കാർ തലത്തിൽ നടപ്പിലാക്കുന്നു, നിങ്ങളുടെ പൈത്തൺ കോഡിൽ അല്ല, ഇത് വളരെ സുരക്ഷിതവും ഓഡിറ്റ് ചെയ്യാൻ കഴിയുന്നതുമാക്കുന്നു.
4. ഫ്ലെക്സിബിൾ ട്രാഫിക് മാനേജ്മെൻ്റ്
ഇത് ഒരു സർവീസ് മെഷിൻ്റെ ഏറ്റവും ശക്തമായ സവിശേഷതകളിലൊന്നാണ്, ഇത് നിങ്ങളുടെ സിസ്റ്റത്തിലൂടെ ട്രാഫിക് എങ്ങനെ ഒഴുകുന്നു എന്നതിനെക്കുറിച്ച് കൃത്യമായ നിയന്ത്രണം നൽകുന്നു.
- ഡൈനാമിക് റൂട്ടിംഗ്: ഹെഡറുകൾ, കുക്കികൾ അല്ലെങ്കിൽ മറ്റ് മെറ്റാഡാറ്റ എന്നിവ അടിസ്ഥാനമാക്കി അഭ്യർത്ഥനകൾ റൂട്ട് ചെയ്യുക. ഉദാഹരണത്തിന്, ഒരു പ്രത്യേക HTTP ഹെഡർ പരിശോധിക്കുന്നതിലൂടെ ഒരു സേവനത്തിൻ്റെ പുതിയ പതിപ്പിലേക്ക് ബീറ്റാ ഉപയോക്താക്കളെ റൂട്ട് ചെയ്യുക.
- കാനറി റിലീസുകൾ & A/B ടെസ്റ്റിംഗ്: ശതമാനം അനുസരിച്ച് ട്രാഫിക് വിഭജിച്ച് സങ്കീർണ്ണമായ വിന്യാസ തന്ത്രങ്ങൾ നടപ്പിലാക്കുക. ഉദാഹരണത്തിന്, നിങ്ങളുടെ പൈത്തൺ സേവനത്തിൻ്റെ പതിപ്പ് `v1` ലേക്ക് 90% ട്രാഫിക്കും പുതിയ `v2` ലേക്ക് 10% ട്രാഫിക്കും അയയ്ക്കുക. നിങ്ങൾക്ക് `v2` ൻ്റെ മെട്രിക്കുകൾ നിരീക്ഷിക്കാൻ കഴിയും, എല്ലാം ശരിയായി കാണുകയാണെങ്കിൽ, `v2` 100% കൈകാര്യം ചെയ്യുന്നതുവരെ കൂടുതൽ ട്രാഫിക് ക്രമേണ മാറ്റുക.
- പിഴവ് കുത്തിവയ്ക്കൽ: നിങ്ങളുടെ സിസ്റ്റത്തിൻ്റെ പ്രതിരോധശേഷി പരീക്ഷിക്കാൻ, നിങ്ങൾക്ക് പ്രത്യേക അഭ്യർത്ഥനകൾക്കായി HTTP 503 പിഴവുകൾ അല്ലെങ്കിൽ നെറ്റ്വർക്ക് കാലതാമസം പോലുള്ള പിഴവുകൾ മനഃപൂർവ്വം കുത്തിവെക്കാൻ മെഷ് ഉപയോഗിക്കാൻ കഴിയും. യഥാർത്ഥ തടസ്സം ഉണ്ടാകുന്നതിന് മുമ്പ് ഇത് ബലഹീനതകൾ കണ്ടെത്താനും പരിഹരിക്കാനും സഹായിക്കുന്നു.
നിങ്ങളുടെ സർവീസ് മെഷ് തിരഞ്ഞെടുക്കുന്നു: ഒരു ആഗോള കാഴ്ച
നിരവധി പരിപക്വവും, ഓപ്പൺ-സോഴ്സ് ആയതുമായ സർവീസ് മെഷുകൾ ലഭ്യമാണ്. നിങ്ങളുടെ സ്ഥാപനത്തിൻ്റെ ആവശ്യകതകൾ, നിലവിലുള്ള പരിസ്ഥിതി, പ്രവർത്തനപരമായ ശേഷി എന്നിവയെ ആശ്രയിച്ചിരിക്കും തിരഞ്ഞെടുപ്പ്. ഏറ്റവും പ്രമുഖരായ മൂന്ന് പേർ ഇസ്റ്റിയോ, ലിങ്കർഡി, കൺസൾ എന്നിവരാണ്.
ഇസ്റ്റിയോ
- ഓവർവ്യൂ: ഗൂഗിൾ, ഐബിഎം, മറ്റുള്ളവർ എന്നിവയുടെ പിന്തുണയോടെ, ഇസ്റ്റിയോ ഏറ്റവും ഫീച്ചർ-റിച്ച് ആയതും ശക്തവുമായ സർവീസ് മെഷാണ്. ഇത് യുദ്ധത്തിൽ പരീക്ഷിക്കപ്പെട്ട Envoy പ്രോക്സി ഉപയോഗിക്കുന്നു.
- ശക്തികൾ: ട്രാഫിക് മാനേജ്മെൻ്റിൽ സമാനതകളില്ലാത്ത വഴക്കം, ശക്തമായ സുരക്ഷാ നയങ്ങൾ, ഊർജ്ജസ്വലമായ പരിസ്ഥിതി. സങ്കീർണ്ണമായ, എന്റർപ്രൈസ്-ഗ്രേഡ് വിന്യാസങ്ങൾക്ക് ഇത് ഡി ഫാക്ടോ സ്റ്റാൻഡേർഡാണ്.
- പരിഗണനകൾ: അതിൻ്റെ ശക്തി സങ്കീർണ്ണതയോടെയാണ് വരുന്നത്. പഠന സാധ്യത കഠിനമായേക്കാം, കൂടാതെ മറ്റ് മെഷുകളുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഇതിന് ഉയർന്ന റിസോഴ്സ് ഓവർഹെഡ് ഉണ്ട്.
ലിങ്കർഡി
- ഓവർവ്യൂ: ഒരു CNCF (Cloud Native Computing Foundation) ഗ്രാജ്വേറ്റ് പ്രോജക്റ്റ്, ഇത് ലാളിത്യം, പ്രകടനം, പ്രവർത്തനപരമായ എളുപ്പം എന്നിവയ്ക്ക് മുൻഗണന നൽകുന്നു.
- ശക്തികൾ: ഇൻസ്റ്റാൾ ചെയ്യാനും ആരംഭിക്കാനും ഇത് വളരെ എളുപ്പമാണ്. റസ്റ്റിൽ എഴുതിയ അതിൻ്റെ അതിവേഗ, അതി-ലൈറ്റ്വെയ്റ്റ് പ്രോക്സി കാരണം ഇതിന് വളരെ കുറഞ്ഞ റിസോഴ്സ് ഫുട്പ്രിൻ്റ് ഉണ്ട്. mTLS പോലുള്ള സവിശേഷതകൾ പൂജ്യം കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് ഔട്ട്-ഓഫ്-ദി-ബോക്സിൽ പ്രവർത്തിക്കുന്നു.
- പരിഗണനകൾ: ഇതിന് കൂടുതൽ അഭിപ്രായഭിന്നതയുള്ളതും കേന്ദ്രീകൃതവുമായ സവിശേഷതകളുണ്ട്. നിരീക്ഷണം, വിശ്വാസ്യത, സുരക്ഷ എന്നിവയുടെ പ്രധാന ഉപയോഗ കേസുകൾ ഇത് മികച്ച രീതിയിൽ കൈകാര്യം ചെയ്യുന്നുണ്ടെങ്കിലും, ഇസ്റ്റിയോയുടെ ചില നൂതനവും വിചിത്രവുമായ ട്രാഫിക് റൂട്ടിംഗ് കഴിവുകൾ ഇതിനില്ല.
കൺസൾ കണക്റ്റ്
- ഓവർവ്യൂ: HashiCorp ടൂളുകളുടെ വിശാലമായ സ്യൂട്ടിൻ്റെ (Terraform, Vault എന്നിവ ഉൾപ്പെടുന്ന) ഭാഗം. വിവിധ പ്ലാറ്റ്ഫോം പരിതസ്ഥിതികൾക്ക് അതിൻ്റെ പ്രധാന വ്യത്യാസം ആദ്യകാല പിന്തുണയാണ്.
- ശക്തികൾ: ഒന്നിലധികം കുബർനെറ്റെസ് ക്ലസ്റ്ററുകൾ, വ്യത്യസ്ത ക്ലൗഡ് പ്രൊവൈഡർമാർ, വെർച്വൽ മെഷീനുകൾ അല്ലെങ്കിൽ ബെയർ-മെറ്റൽ സെർവറുകൾ എന്നിവ ഉൾക്കൊള്ളുന്ന ഹൈബ്രിഡ് പരിതസ്ഥിതികൾക്ക് ഇത് ഏറ്റവും മികച്ചതാണ്. കൺസൾ സർവീസ് കാറ്റലോഗുമായുള്ള അതിൻ്റെ സംയോജനം സുഗമമാണ്.
- പരിഗണനകൾ: ഇത് ഒരു വലിയ ഉൽപ്പന്നത്തിൻ്റെ ഭാഗമാണ്. നിങ്ങൾക്ക് ഒരു കുബർനെറ്റെസ് ക്ലസ്റ്ററിന് മാത്രം ഒരു സർവീസ് മെഷ് ആവശ്യമുണ്ടെങ്കിൽ, കൺസൾ നിങ്ങൾക്ക് ആവശ്യമായതിലും കൂടുതലായിരിക്കാം.
പ്രായോഗിക നടപ്പാക്കൽ: ഒരു പൈത്തൺ മൈക്രോസർവീസിനെ ഒരു സർവീസ് മെഷിലേക്ക് ചേർക്കുന്നു
ഇസ്റ്റിയോ പോലുള്ള ഒരു മെഷിലേക്ക് ഒരു ലളിതമായ പൈത്തൺ ഫാസ്റ്റ്എപിഐ സേവനം എങ്ങനെ ചേർക്കാമെന്ന് ഞങ്ങൾ ഒരു ആശയപരമായ ഉദാഹരണത്തിലൂടെ നടന്നുപോകാം. ഈ പ്രക്രിയയുടെ ഭംഗി നിങ്ങളുടെ പൈത്തൺ ആപ്ലിക്കേഷനിൽ നിങ്ങൾ എത്രമാത്രം മാറ്റേണ്ടതുണ്ട് എന്നതാണ്.
സാഹചര്യം
ഞങ്ങൾക്ക് പൈത്തൺ ഫാസ്റ്റ്എപിഐ ഉപയോഗിച്ച് നിർമ്മിച്ച ഒരു ലളിതമായ `user-service` ഉണ്ട്. ഇതിന് ഒരു എൻഡ്പോയിൻ്റ് ഉണ്ട്: `/users/{user_id}`.
ഘട്ടം 1: പൈത്തൺ സേവനം (മെഷ്-നിർദ്ദിഷ്ട കോഡ് ഇല്ല)
നിങ്ങളുടെ ആപ്ലിക്കേഷൻ കോഡ് ശുദ്ധമായ ബിസിനസ്സ് ലോജിക് ആയി തുടരുന്നു. ഇസ്റ്റിയോ, ലിങ്കർഡി, അല്ലെങ്കിൽ എൻവോയിക്കായി ഇറക്കുമതികളൊന്നുമില്ല.
main.py:
from fastapi import FastAPI
app = FastAPI()
users_db = {
1: {"name": "Alice", "location": "Global"},
2: {"name": "Bob", "location": "International"}
}
@app.get("/users/{user_id}")
def read_user(user_id: int):
return users_db.get(user_id, {"error": "User not found"})
തുടർന്നു വരുന്ന `Dockerfile` സാധാരണമാണ്, പ്രത്യേക മാറ്റങ്ങളൊന്നും ഉൾക്കൊള്ളുന്നില്ല.
ഘട്ടം 2: കുബർനെറ്റെസ് വിന്യാസം
നിങ്ങളുടെ സേവനത്തിൻ്റെ വിന്യാസവും സേവനവും സ്റ്റാൻഡേർഡ് കുബർനെറ്റെസ് YAML ൽ നിങ്ങൾ നിർവചിക്കുന്നു. വീണ്ടും, ഈ ഘട്ടത്തിൽ സർവീസ് മെഷിന് പ്രത്യേകമായി ഒന്നുമില്ല.
apiVersion: apps/v1
kind: Deployment
metadata:
name: user-service-v1
spec:
replicas: 1
selector:
matchLabels:
app: user-service
version: v1
template:
metadata:
labels:
app: user-service
version: v1
spec:
containers:
- name: user-service
image: your-repo/user-service:v1
ports:
- containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
name: user-service
spec:
selector:
app: user-service
ports:
- port: 80
targetPort: 8000
ഘട്ടം 3: സൈഡ്കാർ പ്രോക്സി കുത്തിവയ്ക്കുന്നു
ഇവിടെയാണ് മാജിക് സംഭവിക്കുന്നത്. നിങ്ങളുടെ കുബർനെറ്റെസ് ക്ലസ്റ്ററിൽ നിങ്ങളുടെ സർവീസ് മെഷ് (ഉദാഹരണത്തിന്, ഇസ്റ്റിയോ) ഇൻസ്റ്റാൾ ചെയ്ത ശേഷം, നിങ്ങൾ ഓട്ടോമാറ്റിക് സൈഡ്കാർ കുത്തിവയ്ക്കൽ പ്രവർത്തനക്ഷമമാക്കുന്നു. ഇസ്റ്റിയോയ്ക്ക്, നിങ്ങളുടെ നെയിംസ്പേസിന് ഇത് ഒരു തവണ കമാൻഡ് ആണ്:
kubectl label namespace default istio-injection=enabled
ഇപ്പോൾ, നിങ്ങൾ `kubectl apply -f your-deployment.yaml` ഉപയോഗിച്ച് നിങ്ങളുടെ `user-service` വിന്യസിക്കുമ്പോൾ, ഇസ്റ്റിയോ കൺട്രോൾ പ്ലെയിൻ പോഡ് നിർമ്മിക്കുന്നതിന് മുമ്പ് പോഡ് സ്പെസിഫിക്കേഷൻ യാന്ത്രികമായി മാറ്റുന്നു. ഇത് പോഡിലേക്ക് Envoy പ്രോക്സി കണ്ടെയ്നർ ചേർക്കുന്നു. നിങ്ങളുടെ പോഡിന് ഇപ്പോൾ രണ്ട് കണ്ടെയ്നറുകൾ ഉണ്ട്: നിങ്ങളുടെ പൈത്തൺ `user-service` ഉം `istio-proxy` ഉം. നിങ്ങൾ നിങ്ങളുടെ YAML ൽ യാതൊന്നും മാറ്റേണ്ടതില്ല.
ഘട്ടം 4: സർവീസ് മെഷ് നയങ്ങൾ പ്രയോഗിക്കുന്നു
നിങ്ങളുടെ പൈത്തൺ സേവനം ഇപ്പോൾ മെഷിൻ്റെ ഭാഗമാണ്! അതിലേക്കും അതിൽ നിന്നുമുള്ള എല്ലാ ട്രാഫിക്കും പ്രോക്സി ചെയ്യപ്പെടുന്നു. നിങ്ങൾക്ക് ഇപ്പോൾ ശക്തമായ നയങ്ങൾ പ്രയോഗിക്കാൻ കഴിയും. നിങ്ങളുടെ നെയിംസ്പേസിലെ എല്ലാ സേവനങ്ങൾക്കും കർശനമായ mTLS നടപ്പിലാക്കാം.
peer-authentication.yaml:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: default
spec:
mtls:
mode: STRICT
ഈ ലളിതമായ YAML ഫയൽ പ്രയോഗിക്കുന്നതിലൂടെ, നിങ്ങൾക്ക് നെയിംസ്പേസിലെ എല്ലാ സേവന-ടു-സേവന ആശയവിനിമയത്തെയും എൻക്രിപ്റ്റ് ചെയ്യുകയും പ്രാമാണീകരിക്കുകയും ചെയ്തു. ഇത് പൂജ്യം ആപ്ലിക്കേഷൻ കോഡ് മാറ്റങ്ങളോടെയുള്ള ഒരു വലിയ സുരക്ഷാ നേട്ടമാണ്.
ഇനി നമുക്ക് കാനറി റിലീസ് നടത്താൻ ഒരു ട്രാഫിക് റൂട്ടിംഗ് നിയമം സൃഷ്ടിക്കാം. നിങ്ങൾ ഒരു `user-service-v2` വിന്യസിച്ചിട്ടുണ്ടെന്ന് കരുതുക.
virtual-service.yaml:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: user-service
spec:
hosts:
- user-service
http:
- route:
- destination:
host: user-service
subset: v1
weight: 90
- destination:
host: user-service
subset: v2
weight: 10
ഈ `VirtualService` ഉം അനുബന്ധ `DestinationRule` ഉം (ഇത് `v1` ഉം `v2` ഉം സബ്സെറ്റുകൾ നിർവചിക്കുന്നു) ഉപയോഗിച്ച്, നിങ്ങൾ നിങ്ങളുടെ പഴയ സേവനത്തിലേക്ക് 90% ട്രാഫിക്കും പുതിയതിലേക്ക് 10% ട്രാഫിക്കും അയക്കാൻ ഇസ്റ്റിയോവിനോട് നിർദ്ദേശിച്ചു. ഇതെല്ലാം അടിസ്ഥാന സൗകര്യ തലത്തിൽ ചെയ്യുന്നു, പൈത്തൺ ആപ്ലിക്കേഷനുകൾക്കും അവയെ വിളിക്കുന്നവർക്കും പൂർണ്ണമായും സുതാര്യമാണ്.
ഒരു സർവീസ് മെഷ് എപ്പോൾ ഉപയോഗിക്കണം? (എപ്പോൾ ഉപയോഗിക്കരുത്)
ഒരു സർവീസ് മെഷ് ഒരു ശക്തമായ ഉപകരണമാണ്, പക്ഷേ ഇത് ഒരു സാർവത്രിക പരിഹാരമല്ല. ഇത് സ്വീകരിക്കുന്നത് കൈകാര്യം ചെയ്യാൻ മറ്റൊരു അടിസ്ഥാന സൗകര്യ ലേയർ കൂട്ടിച്ചേർക്കുന്നു.
ഒരു സർവീസ് മെഷ് സ്വീകരിക്കുമ്പോൾ:
- നിങ്ങളുടെ മൈക്രോസർവീസുകളുടെ എണ്ണം വർദ്ധിക്കുമ്പോൾ (സാധാരണയായി 5-10 സേവനങ്ങൾക്ക് മുകളിൽ), അവയുടെ ആശയവിനിമയം കൈകാര്യം ചെയ്യുന്നത് ഒരു തലവേദനയായി മാറുന്നു.
- പൈത്തൺ, ഗോ, ജാവ എന്നിവയിൽ എഴുതിയ സേവനങ്ങൾക്കായി സ്ഥിരമായ നയങ്ങൾ നടപ്പിലാക്കുന്നത് ഒരു ആവശ്യകതയായിട്ടുള്ള ഒരു പോളിഗ്ലോട്ട് പരിതസ്ഥിതിയിൽ നിങ്ങൾ പ്രവർത്തിക്കുന്നു.
- നിങ്ങൾക്ക് കർശനമായ സുരക്ഷ, നിരീക്ഷണം, പ്രതിരോധശേഷി ആവശ്യകതകൾ എന്നിവയുണ്ട്, അത് ആപ്ലിക്കേഷൻ തലത്തിൽ നിറവേറ്റാൻ പ്രയാസമാണ്.
- നിങ്ങളുടെ സ്ഥാപനത്തിൽ പ്രത്യേകം വികസന, പ്രവർത്തന ടീമുകൾ ഉണ്ട്, ഡെവലപ്പർമാർക്ക് ബിസിനസ്സ് ലോജിക്കിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു, അതേസമയം ഓപ്പറേഷൻസ് ടീം പ്ലാറ്റ്ഫോം കൈകാര്യം ചെയ്യുന്നു.
- നിങ്ങൾ കണ്ടെയ്നർ ഓർക്കസ്ട്രേഷനിൽ, പ്രത്യേകിച്ച് കുബർനെറ്റെസിൽ, ശക്തമായി നിക്ഷേപിച്ചിട്ടുണ്ട്, അവിടെ സർവീസ് മെഷുകൾ ഏറ്റവും സുഗമമായി സംയോജിപ്പിക്കുന്നു.
പ്രత్యాമ്നായങ്ങൾ പരിഗണിക്കുമ്പോൾ:
- നിങ്ങൾക്ക് ഒരു മോണോലിത്ത് അല്ലെങ്കിൽ ഏതാനും സേവനങ്ങൾ മാത്രമേയുള്ളൂ. മെഷിൻ്റെ പ്രവർത്തനപരമായ ഭാരം അതിൻ്റെ പ്രയോജനങ്ങളെ മറികടക്കും.
- നിങ്ങളുടെ ടീം ചെറുതാണ്, പുതിയതും സങ്കീർണ്ണവുമായ അടിസ്ഥാന സൗകര്യ ഘടകം പഠിക്കാനും കൈകാര്യം ചെയ്യാനും ശേഷിയില്ല.
- നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ഏറ്റവും കുറഞ്ഞ കാലതാമസം ആവശ്യപ്പെടുന്നു, സൈഡ്കാർ പ്രോക്സി കൂട്ടിച്ചേർക്കുന്ന മൈക്രോസെക്കൻഡ് ലെവൽ ഓവർഹെഡ് നിങ്ങളുടെ ഉപയോഗ കേസിന് അംഗീകരിക്കാൻ കഴിയില്ല.
- നിങ്ങളുടെ വിശ്വാസ്യതയും പ്രതിരോധശേഷി ആവശ്യകതകളും ലളിതമാണ്, നന്നായി പരിപാലിക്കപ്പെടുന്ന ആപ്ലിക്കേഷൻ തലത്തിലുള്ള ലൈബ്രറികൾ ഉപയോഗിച്ച് മതിയാകും.
ഉപസംഹാരം: നിങ്ങളുടെ പൈത്തൺ മൈക്രോസർവീസുകൾക്ക് ശക്തി പകരുക
മൈക്രോസർവീസസ് യാത്ര വികസനത്തോടെ ആരംഭിക്കുന്നു, പക്ഷേ വേഗത്തിൽ ഒരു പ്രവർത്തനപരമായ വെല്ലുവിളിയായി മാറുന്നു. നിങ്ങളുടെ പൈത്തൺ അടിസ്ഥാനമാക്കിയുള്ള വിതരണ സംവിധാനം വളരുന്നതിനനുസരിച്ച്, നെറ്റ്വർക്കിംഗ്, സുരക്ഷ, നിരീക്ഷണം എന്നിവയുടെ സങ്കീർണ്ണതകൾ വികസന ടീമുകളെ അമിതമായി ഭാരപ്പെടുത്തുകയും നൂതനതയെ മന്ദഗതിയിലാക്കുകയും ചെയ്യും.
ഒരു സർവീസ് മെഷ് ഈ വെല്ലുവിളികളെ നേരിടുന്നത് അവയെ ആപ്ലിക്കേഷനിൽ നിന്ന് абстраക്റ്റ് ചെയ്ത് ഒരു സമർപ്പിത, ഭാഷാ-അജ്ഞാതമായ അടിസ്ഥാന സൗകര്യ ലേയറിലേക്ക് മാറ്റുന്നു. ഇത് സേവനങ്ങൾക്കിടയിലുള്ള ആശയവിനിമയത്തെ നിയന്ത്രിക്കാനും സുരക്ഷിതമാക്കാനും നിരീക്ഷിക്കാനും ഒരു ഏകീകൃത മാർഗ്ഗം നൽകുന്നു, അവ ഏത് ഭാഷയിൽ എഴുതിയിരുന്നാലും.
ഇസ്റ്റിയോ അല്ലെങ്കിൽ ലിങ്കർഡി പോലുള്ള ഒരു സർവീസ് മെഷ് സ്വീകരിക്കുന്നതിലൂടെ, നിങ്ങളുടെ പൈത്തൺ ഡെവലപ്പർമാർക്ക് അവർ ഏറ്റവും മികച്ചത് ചെയ്യാൻ കഴിയും: മികച്ച ഫീച്ചറുകൾ നിർമ്മിക്കുകയും ബിസിനസ്സ് മൂല്യം നൽകുകയും ചെയ്യുക. സങ്കീർണ്ണമായ, ബോയിലർപ്ലേറ്റ് നെറ്റ്വർക്കിംഗ് ലോജിക് നടപ്പിലാക്കുന്നതിൻ്റെ ഭാരത്തിൽ നിന്ന് അവർക്ക് മോചനം ലഭിക്കുകയും പകരം പ്രതിരോധശേഷി, സുരക്ഷ, ഉൾക്കാഴ്ച എന്നിവ നൽകുന്ന പ്ലാറ്റ്ഫോമിനെ ആശ്രയിക്കുകയും ചെയ്യാം. അതിൻ്റെ മൈക്രോസർവീസസ് ആർക്കിടെക്ചർ വളർത്താൻ ഗൗരവമുള്ള ഏതൊരു സ്ഥാപനത്തിനും, ഒരു സർവീസ് മെഷ് ഒരു തന്ത്രപരമായ നിക്ഷേപമാണ്, അത് വിശ്വാസ്യത, സുരക്ഷ, ഡെവലപ്പർ ഉത്പാദനക്ഷമത എന്നിവയിൽ ലാഭം നൽകുന്നു.